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We propose a path-based approach to program repair for imperative programs. Our repair framework 
takes as input a faulty program, a logic specihcation that is refuted, and a hint where the fault may 
be located. An iterative abstraction rehnement loop is then used to repair the program: in each 
iteration, the faulty program part is re-synthesized considering a symbolic counterexample, where 
the control-flow is kept concrete but the data-flow is symbolic. The appeal of the idea is two-fold: 
1) the approach lazily considers candidate repairs and 2) the repairs are directly derived from the 
logic specification. In contrast to prior work, our approach is complete for programs with finitely 
many control-flow paths, i.e., the program is repaired if and only if it can be repaired at the specified 
fault location. Initial results for small programs indicate that the approach is useful for debugging 
programs in practice. 


1 Introduction 


Debugging is one of the most frequent and challenging activities in software development. In order to fix 
a faulty program without introducing new bugs or subtle comer cases, an in-depth understanding of the 
source code is required. Error hints and counterexamples produced by static analysis or model checking 
tools are only of little help: they typically report a symptom of a failure but do not point to the actual 
cause or provide a repair for a program. Manually correcting a faulty program based on this information 
is hard and often becomes an iterative trial-and-error process driven by a developer’s intuition. 

Automatic program repair techniques aim at reducing this manual burden by utilizing a refuted logic 
specification to automatically compute a repair for a faulty program. Existing approaches mainly suffer 
from two problems: 1) they do not scale well to large programs or 2) they rely on structural restrictions 
of the considered repairs. The two problems are orthogonal. Scalability issues originate from the fact 
that correctness of the entire program is modeled. Structural restrictions allow for the enumeration of 
potential repairs and make the repairs more readable ||3. The choice of the “right” structure for a repair, 
however, is left to the user or guided by a brute-force search. Bad choices cause an exclusion of suitable 
repairs. 

In this paper, we take program repair one step further and address these two problems with a novel ap¬ 
proach, called path-based program repair. The approach combines symbolic path reasoning and software 
synthesis. We present a repair framework to automatically correct a faulty imperative program based on 
an iterative abstraction refinement loop, assuming that the location of the fault is known. Eor instance, 
the location may be guessed by a user or computed using a fault localization approach, e.g., ITTI IT^ . 

In each iteration of the loop, a model checker computes a symbolic counterexample. Symbolic coun¬ 
terexamples keep the data-flow symbolic buf fhe confrol-fiow concrefe. Symbolic pafh reasoning fhen 
infers verificalion conditions in fhe local confexf of fhe faulfy program parf. The inferred verification 
conditions are used fo formulafe a synthesis problem. The faulty program part is then re-synthesized in 
order to exclude all symbolic counterexamples found so far. Consequently, the synthesized candidate re¬ 
pair corrects the program with respect to the considered symbolic counterexamples. The loop terminates 
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when no further symbolie eounterexamples are found and is guaranteed to converge for programs with 
finitely many control-flow paths (provided that the model checker and the synthesis procedure do not 
diverge). 

The appeal of the idea is two-fold: 1) our approach lazily repairs a faulty program by inferring 
verification conditions from counterexamples utilizing symbolic path reasoning and 2) the repairs are 
derived from the refuted logic specification using software synthesis. Symbolic path reasoning, on the 
one hand, has been effectively used to cope with scalability. Software synthesis, on the other hand, does 
not restrict candidate repairs to have a predefined structure ISIS, such as linear expressions over program 
variables. 

Path-based program repair establishes a framework for fixing faulty programs, building on existing 
ideas, but tunes them to specifically address program repair. Naively combining prior work is problem¬ 
atic: applying predicate abstraction |@1 leads to coarse abstractions that are just good enough to either 
verify the program or refute its correctness along one of its executions. Thus, the abstraction is insuffi¬ 
cient to subsequently find a “good” repair for the program, which should work for most, if not all, cases. 
Recent software synthesis approaches, e.g., those for the Syntax-Guided Synthesis (SyGuS) [Jj prob¬ 
lem, cannot decide realizability, which is crucial for termination in case the initially given fault locations 
cannot be repaired. 

Contribution. The contribution of the paper can be summarized as follows: 

1. an iterative abstraction refinement approach for program repair combining symbolic path reasoning 
and software synthesis, called path-based program repair; 

2. a prototype implementation of the repair framework utilizing domain finitizing and synthesis based 
on Binary Decision Diagrams (BDD), which allows deciding realizability; 

3. initial experimental results for our prototype on a small ANSTC program. 

The remainder of the paper is structured as follows: in Sec.[^ we describe the necessary background 
and in Sec.|^ we present path-based program repair. Sec.j^is dedicated to our prototype implementation 
utilizing domain finitizing and BDD-based synthesis. We also give experimental results for a small 
ANSTC program. Sec. [^concludes the paper. 

2 Background 

2.1 Program and Specification 

We focus on sequential, finite-state systems described in a high-level programming language like ANST 
C. Let Stmts be the set of all statements, a program corresponds to a finite-state automaton over Stmts, 
called program automaton, with control locations as nodes and program operations as edges. Without 
loss of generality, we assume that each program automaton has a distinguished entry node and a distin¬ 
guished exit node denoting the program’s entry and the program’s exit. 

Our approach to program repair is dedicated to static analysis of individual control-flow paths of a 
program. A control-flow path is a consecutive sequence of nodes starting at the entry node and ending at 
the exit node, i.e., a word in the language of the program automaton, which corresponds to a terminating 
execution of the program and respects the semantics of the statements. Loops are unrolled and decisions 
at branching points in the program are modeled, e.g., if or while statements are replaced with respective 
assumption statements. More formally, a control-flow path tt = is a sequence of side-effect free 

statements given in Static Single Assignment (SSA) form, where each Si is either an assumption statement 
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// ip {x = 0} 

1. assume (x < 2); 

// {x = 0 A x < 2} 4^ {x = 0} 

2. X = X + 1; 

// {x=l} 

3. assume (x < 2); 

// {x = 1 A X < 2} 44 {x = 1} 

4. x = X + 1; 

// {x = 2} 

5. assume (!(x < 2)); 

// {x = 2 A ^(x < 2)} 44 {x = 2} 


// {true} 

1. assume(x < 2); 

// {true} 

2. X = X + 1; 

//{(x<2) ^ x<l} 44 {true} 

3. assume(x < 2); 

// {x+1 < 2} 44 {x< 1} 

4. X = X + 1; 

//{-(x<2) ^ x = 2} 44 {x<2} 

5. assumed (x < 2)); 

// I// :44 {x = 2} 


Figure 1: Predicate propagation along a control-flow path. 


or an assignment statement. Along a fixed control-flow path, computing SSA form is straightforward 
because the costly placement of 0-nodes to assemble the control-flow from different control-flow paths 
is not necessary. An assignment statement is of form v : = e, where v is a program variable and e is 
an expression over program variables and constants. An assumption statement is of form assume (c), 
where c is a condition over the program variables and constants. We assume that the concatenation 
operation • is defined for a control-flow path 7t = s\S 2 - ■ -Sn in the usual form such that the control-flow 
path can be represented as it = Ha-S n, it = s\- tza, or n = tza- tzb- 

A (program) state a is a valuation of all program variables, i.e., a mapping from the program variables 
to values within the respective domains. The specification is given as a precondition and a postcondi¬ 
tion. The precondition defines the set of program states initially possible at the program’s entry. The 
postcondition defines the set of program states allowed at the program’s exit. We say that a program P is 
correct if and only if (iff) all executions starting in a state a specified by the precondition reach a state o' 
on termination that fulfills the postcondition. Otherwise we say that P is faulty. 

In the following, sets of states are symbolically represented utilizing First-Order Logic (FOL) for¬ 
mula. Let (/) G FOL, we write Vars{(p) and FV{(p) to denote the variables and the free variables of 0, 
respectively. In several parts of the descriptions, we explicitly show that a FOL formula 0 depends on 
a specific variable v by writing (j) [v] and generalize this notation to show the dependence on a list v of 
variables by writing ^[v]. As usual, we call a FOL formula (j) satisfiable iff an assignment to Vars{^) 
exists that makes the formula true and unsatisfiable otherwise. Moreover, we say a FOL formula (/> is 
valid iff (j) is equivalent to true, i.e., (p is true for all assignments to Vars{p). Lastly, 0[x/y] denotes (j) 
where each free occurrence of variable x is replaced by variable y. 

2.2 Symbolic Path Reasoning 

We use Floyd/Hoare style computation to propagate predicates along a control-flow path. This is 
done by applying standard predicate transformers like weakest precondition and strongest postcondition 
to control-flow paths. A predicate transformer is a function pf: FOL x Stmts —FOL that maps a formula 
(p G FOL and a statement s G Stmts to a formula pt{(p ,s) G FOL. 

Definition 2.1. Given a statement s G Stmts executed on state o to produce state o' and a predicate (p G 
FOL, the weakest precondition transformer wp and the strongest postcondition transformer sp compute 

• the weakest predicate wp{(p, s) G FOL, called weakest precondition, that guarantees o |= wp{(p, s) 
if o' € (p and 

• the strongest predicate sp{(p ,s) G FOL, caZZed strongest postcondition, that guarantees o' \=sp(p,s) 
ifoGp, respectively. 
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Let (/) G FOL and s G Stmts, we define the usual mechanic rules to compute the weakest precondi¬ 
tion and the strongest postcondition for the two types of statements that occur in a control-flow path, 
respectively. 


wp((/),assume(c)) c —> 0 

>vp(0,v := e) Vv'.(v' = e —)• ^[v/v']) (/>[v/e] 

5p((/>,assume(c)) A(/> 

5p(0,v := e) 3v'.(v = e[v/v'] A (/>[v/v']), 

and naturally generalize them to sequences 5152 • • • of statements, 

Wp{^,SlS2...Sn) 4^Wp(wp{^,Sn),SlS2---Sn-l) 

Sp{^,SiS2...S„) Sp{sp{^,Si),S2S3---Sn). 

Since loops are already unrolled, no loop invariants have to be found, and thus computing strongest 
postconditions and weakest preconditions along control-flow paths is decidable if the logic in use ad¬ 
mits quantifier elimination. Moreover, note that computing the weakest precondition of an assignment 
statement amounts to replacing a variable by an expression. Thus, the application of costly quantifier 
elimination procedures is not necessary in this case. 

We refer to the application of wp and sp to a given control-flow path n = 51^2 ■■■Sn, i-e., a sequence 
of statements that respect the semantics of a program, and to a FOL formula as backward propagation 
and forward propagation, respectively. 

Example 2.1. In Fig. [7] we apply forward propagation and backward propagation, respectively, to a 
control-flow path 5 i 52 .. ..^ 5 . Forward propagation (on the left) uses the precondition (p 4A {x = 0} and 
the backward propagation (on the right) uses the postcondition i// 4A {x = 2}. 

Definition 2.2. Let n be a control-flow path with precondition (p and postcondition y/- that a 

Hoare triple {^}7 i{y} holds iff the two equal conditions (p —?■ wp(\l/,K) and sp((p,n) —?■ y/ are valid. 
Otherwise, we call K a (symbolic) counterexample/or (p and y. 

This definition differs from the standard connotation of a counterexample given by a concrete input 
assignment returned by a model checking procedure. However, a symbolic counterexample in our sense 
can directly be determined after model checking by interpreting the program on the concrete input as¬ 
signment and logging the corresponding control-flow path; thus, control-flow is concrete but data-flow 
symbolic. 

2.3 Software Synthesis 

We use synthesis to repair faulty programs and treat a synthesis procedure as a black box that derives 
program terms from a logic specification. The logic specification is a predicate <p[x,y] G FOL, where x 
is a set of uncontrollable variables, y is a set of controllable variables, and FV{^) C xUy. A synthesis 
procedure computes terms over x such that replacing all occurrences of y in 0 by their respective term 
yields a valid formula. 

Definition 2.3. A (software) synthesis procedure computes terms T from a given predicate 0 G FOL and 
variables x C FV (0) such that 


Vx.(/>[y/r] 


( 1 ) 
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is valid, where y = FV (</>)\x 

A synthesis procedure may choose not to compute a term or may not terminate. If this can only 
happen if such a term replacement does not exist, i.e., if 

\/x3y.(l) 

is valid, we call a synthesis procedure complete. We also say that a complete synthesis procedure which 
always terminates is able to detect unrealizability. 

Note that this formulation defines a software synthesis problem SO, where we search for a piece 
of terminating code that satisfies a given logic specification. This is in contrast to works on reactive 
synthesis, where a finite-state machine is to be synthesized that executes for an unbounded duration of 
time and satisfies a specification in some temporal logic, i.e., that reasons about the behavior of the 
finite-state machine over time. 

Synthesis corresponds to quantifier eliminafion and synthesis procedures have been provided for 
relations expressed in different decidable logics, e.g.. Boolean logic, linear arithmetic and sets ifTOll . 
unbounded bit-vectors lj5l, term algebras and the theory of integer-indexed arrays with symbolic bounds 
on index ranges @. 

3 Path-Based Program Repair 

3.1 The PBRepair Framework 

The overall PB Repair approach is described as pseudo code shown in Alg. [T] Additionally, Tab.[T]g ives 
a description of the main components used in the algorithm, and Fig. [^describes the interaction between 
them. 

The input to PB Repair is a faulty program P, a logic specification given as a pair of a precondition 
and a postcondition [tp, yr), and an fault region e to be repaired, where e contains assignment statements 
to a set of variables v. The algorithm returns a repaired program P' which is a copy of P but in which the 
code within the fault region e has been replaced by assignment statements to the variables v such that P' 
is correct with respect to (p and y/. 

The algorithm can be seen as an iterative abstraction refinement loop guided by the counterexamples 
provided by a model checker. The algorithm maintains a set IT of counterexamples and modifies a copy P' 
of the program (line 1). In each iteration, three steps are performed: firstly, the program is model checked 
with respect to its logic specification (line 2). If verification succeeds, then the algorithm terminates with 
the currently considered program P' as output. Otherwise, a (symbolic) counterexample 7t is provided 
by the model checker and added to IT (line 3). 

Secondly, a synthesis procedure is invoked with the predicate <I> G FOL and a set of variables y C 
Var((j)) to be synthesized (line 5). The predicate <I> G FOL accumulates the verification conditions by 
propagating the precondition cp and the postcondition y/ to the local context of the fault region e for all 
counterexamples 71 G IT (line 4). For a counterexample 7i = Ha ■ e ■ TIb we use the strongest postcondition 
transformer sp to propagate (p forward and the weakest precondition transformer wp to propagate yr 
backward until reaching the fault region. The variables y are fresh variables replacing v in wp{\l/,ttB) 
and otherwise do not occur in <I>. The terms T produced as a result of synthesis are a repair for the fault 
region e in program P considering all counterexamples in IT. If <I> is unrealizable (line 6-8), then the 
algorithm terminates with an error indicating that the program cannot be repaired in the considered fault 
region e. For instance, this may happen if the initial fault region e has been provided by a user or an 
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Algorithm 1: PBRepair 

input : faulty program P, precondition cp, postcondition i/r, fault region e 
output; repaired program P', such that P' is correct 

1 n:=0,P' :=P 

2 while n := ModelCheck(P',(p,i/r) do 

3 n:=nu{7r} 

4 let<I>:= A {sp{9,^A)^{wp{Y,^B)[v/y])) 

TT/i -e-Tls^Yl 

5 T := Synthesize(<I>,y) 

6 if Unrealizable then 

7 I throw Unable to repair in fault region e. 

8 end 

9 P':= ApplyRepair(/’',e,r) 

10 end 

11 return P' 


/ 

X 



Figure 2: PBRepair: high-level overview of path-based program repair. 


unsound fault localization algorithm. Otherwise, synthesis yields a list of terms T that are used to repair 
the program. 

Thirdly, if the terms T could be computed (line 5), assignment statements to the variables in v are 
generated as a repair to the program in the syntax of the programming language in use. In P', the 
assignment statements replace the statements within the fault region (line 9). The program P' is correct 
(by construction) with respect to (p, y/, and all counterexamples tt G IT. The algorithm loops until a 
correctly repaired program is found or the non-existence of a repair is detected. 

3.2 Correctness and Termination 

Lemma 3.1. Let K = Ka- e-Kgbe a counterexample to precondition (p and postcondition \j/, where e is a 
list of assignment statements := ei that is known to be faulty and Ka and Kb are known to be correct, 
then {y)}KA ■ r ■ Kb{y} holds for the assignment statements r of form r : vi := Ti... Vn := Tn, where 
V = [vi,..., v„] and T = [A,..., r„] is the result of performing synthesis on the specification sp((p, Ka) ^ 
wp{\l/, KB)[v/y]for the output variables y. 
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Name 

ModelCheck 

Input 

Output 

Description 

Source code of a program P, a precondition tp, and a postcondition y/. 

A counterexample if P is faulty and false otherwise. 

Model checks the source code of P assuming tp and asserting t/r and returns a (sym¬ 
bolic) counterexample 7Z. 

Name 

Synthesize 

Input 

Output 

Description 

A predicate (j) and a vector x C FV (0) of controllable variables. 

A vector T of terms if (j) is realizable with respect to <p or throws an exception. 
Computes a vector T of program terms on termination, such that \/x3y.^ —)> \/x.^ \y/T] 
becomes valid. If\/x3y.^ is not valid, i.e., is unsatisfiable, an exception is thrown which 
indicates that the synthesis problem is unrealizable. 

Name 

ApplyRepair 

Input 

Output 

Description 

Source code of program P, a fault region e, and program terms T. 

A repaired copy P' of program P, where all changes are applied to fault region e. 
Transforms the program terms T into source code in the programming language in use 
and replaces them for the right-hand side of the assignment statements in fault region e 
inP'. 


Table 1: A description of the main components used in Alg. [T] 


Proof. The control-flow path tt = • r • TTb is correct with respect to precondition tp and postcondition if/ 
iff {(p}7tA • r- 71 b{y} holds. Let ri,r 2 G FOL be the verification conditions that hold immediately be¬ 
fore and immediately after the execution of the statements r, respectively, such that {(p}7tA ■ r ■ 7tB{Y} 
decomposes to the three Hoare triples Hi : {(p}7rA{ri}, H 2 : {r2}7rB{t/r}, and : {ri}r{r 2 }. Since 
tZa and tib are correct, Hi and H 2 hold, and only Hj, has to be proven. The Hoare triple Hj, holds iff 
(i) Fi —)■ wp{T 2 ,r : vi := Ti... Vji := Tn) is valid (Def |2.2| , which further simplifies to Fi —F 2 [v/r]. 
The Hoare triples Hi and H 2 hold iff (ii) sp{(p, TT/i) —)■ Fi and (iii) F 2 —)• wp(t/r, tib) hold (Def |2.2[ ), respec¬ 
tively. We use (ii) to weaken the left-hand side of (i) and (iii) to strengthen the right-hand side of (i), and 
obtain (iv) sp((p, TZa) —^ wp{\g, tzb) [v/T]. The term replacements T guarantee the validity of implication 
(iv) (Def |2.3| ), and thus H^, and {^}7z{y} hold. □ 

Theorem 3 . 2 . Let P be a program with finitely many control-flow paths, pa/r of a precondi¬ 

tion and a postcondition, and e : vi = wi;... Vn := Wn a fault region in P, then algorithm PBRepair(P, 
(p,Y,e) returns on termination either a program P' correct with respect to (p and if P can be repaired 
in e or otherwise throws an error. 

Proof. Since P is faulty with respect to the specification, model checking in the first step produces a 
counterexample TZ on termination. If the model checking procedure does not terminate, then PBRepair 
does not terminate. If the fault region e is not contained in TZ, then PB Repair terminates with an error 
indicating that P cannot be repaired within the fault region e. This may happen when multiple faults are 
considered. Otherwise, a synthesis procedure is invoked to repair the program P at e. If the procedure 
does not terminate, PB Repair does not terminate. If the synthesis procedure reports unrealizability of the 
specification, no repair exists to make P correct in e and PB Repair throws an error. Otherwise, according 
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to Lemma 3.1 program terms T are synthesized such that the counterexample is removed. In each iter¬ 
ation, at least one counterexample is removed. Since the verification conditions of the counterexamples 
are accumulated, monotonicity is enforced, i.e., previously corrected counterexamples cannot become 
faulty again. Since P has only finitely many control-flow paths, PBRepair terminates after finitely many 
iterations if for all iterations, model checking and synthesis terminate. The finally produced program has 
no counterexamples and fhus is correcf wifh respecf fo (p and t/r. □ 


4 Implementation and Experimental Results 

The repair framework presenfed in fhe previous section is generic in fhe sense fhaf fhe framework can be 
insfanfialed wifh differenf model checkers and synfhesis procedures absfracfing from programming and 
specification languages. In fhis section, we presenf a profofype implemenfafion of fhe repair framework 
for ANSI-C ufilizing domain finifizing and give some inifial experimenfal resulfs indicating fhaf pafh- 
based program repair can be useful for repairing real programs. 

The specificafion, i.e., fhe precondition and posfcondifion, and all ofher logic formula are expressed 
in fhe SMT-LIB2 logic QF_BV, i.e., fhe quanlifier-free fragmenl of firsf-order logic modulo bif-vecfor 
arifhmefic. The manipulation of logic formula for computing weakesf precondifions and sfrongesf posf- 
condifions has been implemenfed using fhe API of fhe fheorem prover Z3 ifTTI . 

Symbolic counferexamples are compufed by leveraging CBMC |[3l in combinafion wifh a self-im- 
plemenfed execution fracer. CBMC model checks fhe program wifh respecf fo fhe given specificafion. 
When verification fails, an inpuf assignmenf is exfracled from CBMC’s logfile. The execufion fracer 
then re-simulates the program with this input assignment and dumps the statements executed in a textual 
representation similar to Fig. 

For synthesis, logic formula are bit-blasted to Boolean functions, more particularly And-Inverter 
Graphs (AIGs), by replacing each word-level variable by individual bit-level variables and each bit- 
vector operator by a corresponding Boolean circuit. After bit-blasting, a BDD-based synthesis procedure 
is applied to obtain a gate-level repair for the program. The synthesis procedure is complete, guarantees 
termination, and thus detects unrealizability. Basing the main synthesis work on BDDs has many advan¬ 
tages — they can perform the quantifier elimination step needed for synthesis in a natural and efficient 
way. Also, the question of how to compute an implementation from an input/output relation that is 
represented as a Boolean function is well-researched, so that we can apply this work. 

In the last step, the gate-level repair is transformed to ANSI-C code in a straight-forward way: for 
each circuit gate o = AND{a,b), a fresh variable o is introduced and assigned to the ANSI-C expres¬ 
sion {a &b), where a and b are either other variables introduced by this conversion or input bits extracted 
from existing word-level program variables. 

Fig. shows minmax, a simple fragment of an ANSI-C program that determines the largest and the 
smallest value of three given inputs. All variables in the program fragment are of integer type. The logic 
specification (p and \p annotated to the source code is complete, so that all possible faults are observable 
during model checking and can be repaired by our approach assuming the “right” fault region is provided 
as input. To improve scalability of synthesis, the bit-widths of integer variables are reduced to 2 bit. 

In order to allow repairing conditional statements of form if (c) { . . .}, where the guard condition c 
may be a complex or compound expression, in a preprocessing step, the conditional statement is replaced 
byt = c; if(t){...}, where f is a new temporary program variable. 

Table 1^ lists some initial experiments, where faults have been seeded into minmax and PB Repair is 
applied to repair them. The table is built as follows: each line corresponds to one seeded fault. The 
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// 

(p {true)' 



1. 

most = input1; 



2. 

least = input1; 



3. 

if (most < input2) 



4. 

most = input2; 



5. 

if (most < inputs) 



6. 

most = inputs; 



7. 

if (input2 < least) 



8. 

least = input2; 



9. 

if (inputs < least) 



10. 

least = inputs; 



// V { 



// 

(most = inputl V most = input2 

V 

most = inputs) A 

// 

(most > inputl A most > input2 

A 

most > inputs) A 

// 

(least = inputl V least = input2 

V 

least = inputs) A 

// 

(least < inputl A least < input2 

A 

least < inputs) } 


Figure 3: minmax program 


Line 

Type 

Iterations 

Control-Flow Path [AND gates] 

Time [s] 

1 

Assignment 

7 

0000[2] 0100[2] 0011 [16] 0110[17] 1010[12] 0010[18] 0001 [7] 

2 

2 

Assignment 

4 

1001 [2] 0100[3] 0000[2] 1000[2] 

3 

3 

Condition 

4 

1110[1] 0000[3] 1010[6] 0001 [8] 

4 

4 

Assignment 

2 

1000[3] 1001 [6] 

3 

5 

Condition 

2 

0101 [1] 0000[5] 

6 

6 

Assignment 

2 

0110[3] 0100[6] 

4 

7 

Condition 

5 

0001 [1] 1010[3] 0100[9] 0000[11] 1110[8] 

4 

8 

Assignment 

3 

0111 [2] 0010[5] 0110[4] 

4 

9 

Condition 

6 

0111[1] 0000[1] 1001 [4] 0011 [8] 1000[18] 0010[20] 

5 

10 

Assignment 

2 

0011 [2] 0001 [14] 

4 


Table 2: Path-Based Program Repair applied to minmax 


first eolumn shows the line number in which a fault was seeded, the second column lists the type of the 
erroneous statement, the third column gives the number of iterations needed by PBRepair to terminate 
and the fourth column lists the examined control-flow paths as bit strings for all iterations and the size of 
the corresponding candidate repair counted in AND gates in squared brackets. Each bit string gig 2 g 3 g 4 
denotes the evaluation of the guard conditions, where gi, g 2 , gs, g 4 correspond to the code lines 3, 5, 
7, 9, respectively. The value 0 and 1 indicate that the respective guard condition evaluated to false and 
true, respectively, when executed. The last column gives the run-time in seconds. All experiments have 
been conducted on Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz with 8GB RAM. The run-time was 
mainly spend in synthesizing the repair and the time required for model checking was negligible. 

The repair framework proposed is fully automated and does not need any human intervention. Our 
initial experiments indicate that PBRepair can be used for repairing simple ANSI-C programs; i.e., the 
prototype implementation of PBRepair proposed was able to determine a repair for each of our seeded 
faults in only a few seconds. However, before applying our repair procedure to minmax, the bit-width 
of integers was manually reduced. Otherwise, quantification on up to 160 BDD variables is necessary 
which is challenging for today’s BDD-based procedures. We claim that automated bit-width abstraction 
refinement for synthesis is in reach such that a synthesize-and-generalize approach is possible: first bit- 
widths are abstracted to a small number of BDD variables, a repair is synthesized from the abstraction, 
generalized to the full bit-widths, and subsequently verified considering the context of the program. 
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5 Conclusion 

In this paper, we presented a path-based abstraction refinement approach to program repair which com¬ 
bines symbolic path reasoning and software synthesis. A prototype implementation of the repair frame¬ 
work has been presented utilizing domain finitizing and BDD-based synthesis. In contrast to other syn¬ 
thesis approaches, this allows for deciding realizability. Initial experimental results for our prototype on 
a small ANSI-C program have been presented. 

The repair framework uses off-the-shelf model checking and synthesis tools, and thus inherits their 
scalability strength and barriers. In case of the BDD-based synthesis the limiting factor is the number 
of input and output variables after bit-blasting, which were manually reduced for our experiments. We 
conjecture that a customized bit-width abstraction refinement approach will substantially improve scala¬ 
bility, while allowing to keep the completeness and unrealizability detecting capabilities of BDD-based 
synthesis. A challenge that remains in this context is to foster readability of the computed implementa¬ 
tion parts. We leave these improvements to future work. 
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